Skip to content

Avoid redundant work in diagnostics pass #1514

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 6 commits into from
Mar 8, 2021
Merged

Avoid redundant work in diagnostics pass #1514

merged 6 commits into from
Mar 8, 2021

Conversation

pepeiborra
Copy link
Collaborator

The diagnostics pass is at least O(FRlog(F)) in the number of Files and Rules. While there's no obvious way to improve the asymptotic, we can avoid some wasted work by skipping rules that never produce diagnostics, like GetDependencyInformation.

Turns out that there are quite a few such rules, so the strategy pays off in large projects.

@pepeiborra pepeiborra changed the title Improve the performance of diagnostics pass Avoid redundant work in diagnostics pass Mar 7, 2021
@ndmitchell
Copy link
Collaborator

Is there any way to encode this statically? E.g. add:

defineNoDiagnostics
    :: IdeRule k v
    => (k -> NormalizedFilePath -> Action v) -> Rules ()

And then pass this information to the underlying super-define, so it knows which rules have no diagnostics, and if they in their type try and produce diagnostics, we get a type error?

If we are doing the more dynamic approach, I'd definitely want an error asserting that it claimed no diagnostics and there were indeed no diagnostics - otherwise we might accidentally lose a diagnostic, which would be awful.

@pepeiborra
Copy link
Collaborator Author

Is there any way to encode this statically? E.g. add:

defineNoDiagnostics
    :: IdeRule k v
    => (k -> NormalizedFilePath -> Action v) -> Rules ()

And then pass this information to the underlying super-define, so it knows which rules have no diagnostics, and if they in their type try and produce diagnostics, we get a type error?

If we are doing the more dynamic approach, I'd definitely want an error asserting that it claimed no diagnostics and there were indeed no diagnostics - otherwise we might accidentally lose a diagnostic, which would be awful.

I like that much better, thanks for the suggestion!

@pepeiborra pepeiborra marked this pull request as draft March 7, 2021 15:20
@pepeiborra pepeiborra marked this pull request as ready for review March 7, 2021 17:56
@pepeiborra pepeiborra force-pushed the HasNoDiagnostics branch 2 times, most recently from 7c75bab to 118ff90 Compare March 8, 2021 06:41
ndmitchell
ndmitchell approved these changes Mar 8, 2021
View reviewed changes
Copy link
Collaborator

@ndmitchell ndmitchell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@pepeiborra pepeiborra added the merge me Label to trigger pull request merge label Mar 8, 2021
@mergify mergify bot merged commit 94573be into master Mar 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ndmitchell ndmitchell ndmitchell approved these changes

Assignees
No one assigned
Labels
merge me Label to trigger pull request merge
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@pepeiborra @ndmitchell @jneira